AWS Verified Access の主要な 4 つのコンポーネント構造を整理してみた

#AWS Verified Access

#AWS

いわさ

2023.05.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

先日 GA となった AWS Verified Access ですが、以下の記事でも登場するように利用する際にはいくつかコンポーネントを構成する必要があります。

主要なものとして以下の 4 つがあります。

Verified Access インスタンス
Verified Access 信頼プロバイダー
Verified Access グループ
Verified Access エンドポイント

厳密にはポリシーも重要なコンポーネントと言えるのですが、マネジメントコンソールや API 上からリソースとして操作するのは上記 4 つです。

一度 Verified Access を構築してみると上記のうちエンドポイントと信頼プロバイダーの基本的な部分は直感的に理解できると思います。

エンドポイントで実際のプライベートアプリケーションへの経路や構成を設定します
信頼プロバイダーでは信頼する IdP やデバイスなどの構成を設定します

しかし、インスタンスとグループについてはまとめるためのリソースグループのようなものかな？くらいで、その実態や使い方がよくわかっていませんでした。
また、インスタンスに対して複数の信頼プロバイダーをアタッチしたり、単独のグループに複数のエンドポイントを構成したりすることが出来ますがどういう時にどう使えば良いのかわからずにこれまで構成していました。

今回それぞれのコンポーネントを複数構成したり組み合わせたりしていくつかわかったことがありますので検証結果などと併せて紹介したいと思います。

先にまとめてみたが...

今回複数のコンポーネントを組み合わせることで Verified Access 全体像として次のような構成になっていることがわかりました。

1 つの構成図でまとめれると理解しやすいのかなと思って作ってみたのですが、私の表現力が不足していました。申し訳ありません。

そこで、ポイントごとに解説したいと思います。

パブリックエンドポイントは Verified Access インスタンスが持っている

Verified Access では、Verified Access エンドポイントを作成し、その時に出力されるエンドポイントに対してパブリックなリクエストを送信することでアクセス元の検証などが発生します。
私は今回検証するまで、実は次のように Verified Access エンドポイントごとにエンドポイントドメインが生成されているのかと思いこんでいました。

しかし、今回複数のエンドポイントを同一の Verified Access インスタンス、あるいは別の Verified Access インスタンスにデプロイしたところ次のように、いくつかのエンドポイントドメインが同じものでした。なんと。

上記を整理してみると、実はエンドポイントドメイン自体は Verified Access インスタンスから提供されているものということがわかりました。
そして、Host ヘッダーによってインスタンス内のリバースプロキシ先を分けているようなイメージです。

構成図を直すと次のような感じになるでしょうか。

なお、単独のインスタンスで複数のエンドポイントをデプロイ出来るので、同一インスタンスにエンドポイントを集中させた場合のパフォーマンス影響について少し気になりましたが、公式ドキュメント上での記述は見当たりませんでした。

Verified Access 信頼プロバイダーは同じタイプを組み合わせることは出来ない

今回一番気になっていて検証したかったのがここです。

Verified Access 信頼プロバイダーは Verified Access インスタンスにアタッチすることで利用されます。
そして Verified Access インスタンスには複数の信頼プロバイダーをアタッチ出来るようになっています。

仮に、次のように IAM Identity Center と Azure AD と、異なる IdP をどちらもアタッチさせるとどうなるのでしょうか。
どちらの認証も必要になるのでしょうか。それともどちらかが認証されていてポリシーをクリア出来ていれば検証済みとみなされるのでしょうか。

結論としては上記の組み合わせは出来ませんでした。
次のように組み合わせてみたところデプロイ時にエラーが発生しました。

:
  HogeInstance:
    Type: AWS::EC2::VerifiedAccessInstance
    Properties: 
      VerifiedAccessTrustProviderIds: 
        - !Ref HogeTrustProvider
        - !Ref HogeTrustProvider2

  HogeTrustProvider:
    Type: AWS::EC2::VerifiedAccessTrustProvider
    Properties: 
      PolicyReferenceName: !Sub ${AWS::StackName}policy
      TrustProviderType: user
      UserTrustProviderType: iam-identity-center

  HogeTrustProvider2:
    Type: AWS::EC2::VerifiedAccessTrustProvider
    Properties: 
      OidcOptions: 
        AuthorizationEndpoint: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/oauth2/v2.0/authorize
        ClientId: 5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7
        ClientSecret: hogesecret
        Issuer: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/v2.0
        Scope: openid
        TokenEndpoint: https://login.microsoftonline.com/5993FDB4-A746-4BF5-BB8B-0F3A1EE3B6A7/oauth2/v2.0/token
        UserInfoEndpoint: https://graph.microsoft.com/oidc/userinfo
      PolicyReferenceName: hoge0512policy
      TrustProviderType: user
      UserTrustProviderType: oidc
:

Stack hoge0521verified: ROLLBACK_FAILED
Messages:
  - HogeInstance: Resource handler returned message: "Cannot have more than 1 VerifiedAccessTrustProvider with TrustProviderType user attached to a VerifiedAccessInstance (Service: Ec2, Status Code: 400, Request ID: daae7d1e-d280-4618-b948-5275848fc653)" (RequestToken: abb43652-186b-2e99-a4fb-7a276f9e59f2, HandlerErrorCode: ServiceLimitExceeded)
  - HogeTrustProvider2 - vatp-0205770612f199966: Resource handler returned message: "VerifiedAccessTrustProvider has existing attachments. Please remove all VerifiedAccessTrustProvider attachments before deleting. (Service: Ec2, Status Code: 400, Request ID: 84c13a39-f519-421f-9bda-24324c8bf537)" (RequestToken: 449d2725-85bf-338e-24ba-bd54c7478707, HandlerErrorCode: InvalidRequest)
failed deploying stack 'hoge0521verified'
iwasa.takahito@HL01200 hoge0521verified %

信頼プロバイダーには TrustProviderType という属性があり、大きく分けるとユーザー信頼プロバイダーとデバイス信頼プロバイダーの 2 つの種類があります。
上記のエラーメッセージはユーザー信頼プロバイダーが既にアタッチされているのでダメだぜ。と言われています。

よく読むとこのあたりは公式ドキュメントにも記述がありました。

You can choose to use either AWS IAM Identity Center (successor to AWS Single Sign-On) or an OpenID Connect-compatible user-identity trust provider.

User-identity trust providers - AWS Verified Access より

You can use device management trust providers with AWS Verified Access. You can use multiple device trust providers with your Verified Access instance.

Device-based trust providers - AWS Verified Access より

よって、次のように IAM Identity Center (ユーザー信頼プロバイダー）と Jamf (デバイス信頼プロバイダー) の組み合わせであれば同一インスタンスへアタッチが可能です。
また、異なるユーザー信頼プロバイダーの場合も同一インスタンスでなければアタッチが可能なので、あるインスタンスは IAM Identity Center + Jamf で検証を行い、別のインスタンスは Azure AD で検証を行う、というようなインスタンスごとに検証方法を分けて使うことが可能です。